RE: [Sip] Can a transaction statelessproxysupportOutbounddraft?Ifyes, how will the response be sent back theUAbehind NAT
"Attila Sipos" <attila.sipos@vegastream.com> Fri, 16 November 2007 18:54 UTC
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It6L5-0001gh-RZ; Fri, 16 Nov 2007 13:54:51 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1It6L3-0001WK-OX for sip-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 13:54:50 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It6L2-0001RN-T8 for sip@ietf.org; Fri, 16 Nov 2007 13:54:49 -0500
Received: from cluster-f.mailcontrol.com ([85.119.2.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It6L1-0000HZ-M4 for sip@ietf.org; Fri, 16 Nov 2007 13:54:48 -0500
Received: from rly09f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly09f.srv.mailcontrol.com (MailControl) with ESMTP id lAGIse0T013136 for <sip@ietf.org>; Fri, 16 Nov 2007 18:54:41 GMT
Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly09f.srv.mailcontrol.com (MailControl) id lAGIs9vL009959 for sip@ietf.org; Fri, 16 Nov 2007 18:54:09 GMT
Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12]) by rly09f-eth0.srv.mailcontrol.com (envelope-sender attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id lAGIrxPL008723; Fri, 16 Nov 2007 18:54:09 +0000 (GMT)
Received: from EXVS02.nasstar-t1.net ([10.2.10.105]) by exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 18:53:03 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [Sip] Can a transaction statelessproxysupportOutbounddraft?Ifyes, how will the response be sent back theUAbehind NAT
Date: Fri, 16 Nov 2007 18:52:26 -0000
Message-ID: <680808427CF931459462C3D78CB5EC60A03029@EXVS02.nasstar-t1.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] Can a transaction statelessproxysupportOutbounddraft?Ifyes, how will the response be sent back theUAbehind NAT
Thread-Index: AcgoaSxHUIkPyOoKSkS5DHEtZ3rQTgAE4QJg
From: Attila Sipos <attila.sipos@vegastream.com>
To: sergiole@tml.hut.fi, sip@ietf.org
X-OriginalArrivalTime: 16 Nov 2007 18:53:03.0169 (UTC) FILETIME=[EA969B10:01C82881]
X-Scanned-By: MailControl A-08-00-02 (www.mailcontrol.com) on 10.70.1.119
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606
Cc:
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org
>> The problem with the above (separated elements) is that there is not >>synchronization about the state of the socket descriptors. As mentioned >>before, if the edge proxy crashes the socket descriptors used immediately >>after reboot could result in delivering messages to different flows. >> >> In my opinion the randomness included in the flow token avoids that to >>happen, since after reboot the flowtoken can not be decoded and/or find an >>existing flow and that cause the return a error response. Yes, absolutely. And this is a problem with stateful proxies too. I have agreed with everything you've said. However, I still think there is a way to do an outbound-compatible edge proxy with a transaction-stateless/call-stateless proxy. So I now go back to say something similar to what I said before. But first, I will refer to something you said in an earlier mail: >> Furthermore my registrar should not store socket descriptors >>due that if the edge proxy crashes, the registrar could have a >>number of descriptor that after the crash belong to other flows. I feel this would not be a problem for a stateless proxy providing that it is not just a raw socket descriptor id that is passed to the registrar. The branch parameter in the Via would need some kind of hashed/encrypted "reboot count" parameter as well as the socket id. Then if the edge-proxy rebooted, it would know that the response coming back is stale. There are many ways to do the hashing/encryption - you could use a method similar to that used in the gruu draft Appendix A.2. ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-sip-gruu-15 .txt So the Via header's branch parameter would contain encoded information about: 1. the flow back to the UA (socket id, IP, port) 2. the reboot count So now I go back to something else you said: >> 2) generate again the flow token for every request (very bad from >>security point of views) and destroys the consistency of the system >>since you can send requests for non existing flows. Note that the >>draft mentions that the flow and the flow token is only created with REGISTERs. So my proposal is generating some kind of flow token (but not THE same "flow token" as used in the REGISTER). So there is the "flow token" as described in the outbound draft and now there is also a "branch flow token" that I am proposing. And, as explained before, the information in the "branch flow token" is used to route responses back to the UA. But the original "flow token" is never changed. The original "flow token" would still be used when forwarding requests to the UA because the Edge Proxy (in your diagram) would've added it to the Path. So requests to the UA would still work. Now I'm not sure about the security aspects. What security problems could there be with "branch flow token" idea? Regards, Attila -----Original Message----- From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi] Sent: 16 November 2007 15:53 To: Attila Sipos Subject: RE: [Sip] Can a transaction statelessproxysupportOutbounddraft?Ifyes, how will the response be sent back theUAbehind NAT > I am starting to see the problems. > > If I understand correctly, your scenario is this... > > REGISTRAR--------PROXY----------NAT---------SIP UA > > Can you confirm? more specifically my scenario is REGISTRAR/PROXY--------EDGEPROXY----------NAT---------SIP UA where PROXY is a traditional SIP proxy > And, since you were talking about scalability, you might also have > REGISTRAR--------PROXY--------PROXY----------NAT---------SIP UA > > is this right? About scalability I was thinking about /EDGEPROXY1\ REGISTRAR/PROXY-------- ----------NAT---------SIP UA \EDGEPROXY2/ So that the UA has flows to EDGEPROXY1 and EDGEPROXY2. I have no experience with registrars, I guess that in your case you have a REGISTRAR/EDGEPROXY in the same process (or group of processes) and not REGISTRAR--------EDGEPROXY (linked by other means). The problem with the above (separated elements) is that there is not synchronization about the state of the socket descriptors. As mentioned before, if the edge proxy crashes the socket descriptors used immediately after reboot could result in delivering messages to different flows. In my opinion the randomness included in the flow token avoids that to happen, since after reboot the flowtoken can not be decoded and/or find an existing flow and that cause the return a error response. Then another entry in the registrar binding will be used, i.e. other flow token. If you have a second edge proxy (that does not crashed at the same time that the first one :) and the flow token belongs to the second edge proxy, the message will reach the UA over a flow previously established to the second edge proxy. BR Sergio Quoting Attila Sipos <attila.sipos@vegastream.com>: > > >>>>>> 3. >>>>>>> In the Via header's branch parameter, it would encode the > required >>>>>>> flow token. >>>>>> >>>>>> Here is the issue : From were you get the flow token? >>>>>> (In my previous email I mentioned 2 options... ) >>>>>> >>>> >>>> OK I'm starting to see your problem. >>>> >>>> The registration record stores the flow token (obviously) >>> >>> It seems that you are integrating the edge proxy and registrar in >>> the > same code, right? > > yes, that's it. > > >>>> And the socket id for the flow would be stored as well (for >>> >>> Can you confirm that you call socket id to the socket/file >>> descriptor > of the connection? > > yes. > >>>> connection-oriented >>>> protocols). So if you received a request on that socket, you could >>>> match that up to one of the registration records and hence, one of > the >>>> flow tokens. >>>> >>> >>> Good approach. I assume that you have available the socket > descriptor >>> in the registrar, so basically you consider storing the socket > descriptor >>> (number) in the registrar tables. Then perhaps using a flow token it > is not >>> necessary since you have available in the socket descriptor all the > information >>> that describes a flow (TCP case). > > That's true. I might not need the flow tokens. > > >>>> I hope I have explained how the flow token might be mapped to the >>>> socket. >>> >>> Yes if my comments above make sense.. >>> >>>> I can now see that my idea wouldn't work for UDP. >>> >>> Now for UDP perhaps you can consider storing the socket descriptor > for >>> UDP and the IP and port for the flow from the NAT. > > yes, that would work I think. > > >>> Furthermore my registrar should not store socket descriptors due > that >>> if the edge proxy crashes, the registrar could have a number of > descriptor >>> that after the crash belong to other flows. >>> >>> I generate the flow token with REGISTER and send it to the >>> registrar (other node). The approach works as the draft says for >>> incoming > requests >>> (to the Calle). Now when the Callee sends requests, and the >>> requests > are >>> sent over the flow, the responses of that request reach first the >>> edge > proxy >>> and it can not forward them to the Callee over the flow, because >>> these responses don't have the flow token (and the flow token is not >>> stored > in >>> the edge proxy)... > > I am starting to see the problems. > > If I understand correctly, your scenario is this... > > REGISTRAR--------PROXY----------NAT---------SIP UA > > Can you confirm? > > And, since you were talking about scalability, you might also have > REGISTRAR--------PROXY--------PROXY----------NAT---------SIP UA > > is this right? > > >>>> But what if you used the gruu in the contact to match up with the > gruu >>>> of a registration? Then the registration record tells tells you > about >>>> the flow token. That would work wouldn't it? >>> >>> I have not background with gruu. Could you recommend what could I > read about it? > > Sorry, I didn't mean gruu, I was mixing up my drafts! > I was just looking for a unique identifier for the UA which is the > sip.instance from the outbound draft (not gruu). > > > Regards, > Attila > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip